The Athena Framework is an open source application framework for Java platform. Additionally, it supports remoting to Adobe Flex.
Since 2008, Jack Li and other developers at AthenaSource have been developing quite a number of cloud SaaS applications for their clients. Initially, they tried many popular frameworks but gave up all of them due to performance issues and painful configurations. Naturally, they started to build a new framework that supports multi-tenancy natively. This was version 1.0 of Athena Framework. This framework was released open source under the LGPL license in Mar 2011.
Contents |
Athena Framework is an enterprise object-relational mapping (ORM) framework that employs metadata as mapping configuration. It simplifies Java web application development by removing the requirement of manual mapping and manual database schema updating. In addition to features like Java object persistence, powerful EJBQL querying execution and comprehensive code generation, Athena has built-in support for multi-tenancy which enables developers to build cloud applications easily. Athena can be easily integrated with other libraries like Struts or Spring to provide full stacks of service.
In Athena, metadata refers to the collection of all entities, attributes and relationships in database modeling for the application. Any change made on metadata reflects immediately in the database schema and domain object classes. For example, when you add a new attribute named fullName to entity Employee, a new column will be automatically inserted to the corresponding table in the database and a new field will be available in the Employee's domain class when you generate the source code.
Athena realizes true rapid application development by allowing developers to implement changes easily and quickly. Let's say, we need to change Person.fullName's type from CHAR(100) to NVARCHAR(256). For those who use traditional ORM frameworks, they need to manually change database table's column type and to update XML or Java annotation mapping configuration, and updates the UI validation code. Such steps are time-consuming and error prone. Athena comes to rescue: you only need to change the attribute type and save it on the user friendly Athena Metadata Workbench. Athena automatically update the database schema and generate updated source code. Developers' productivity gets significant boost by Athena.
When performing EJBQL queries in Athena, you do not need to guess which relationships will be loaded and which will not be loaded. Instead, you can specify explicitly which relationships will be loaded and how they should be loaded. For example, the query below selects Employees with relationships of department and projects:
SELECT e FROM Employee e [e.department:J, e.projects:S]
The relationship prefetch rules in the square brackets specify that relationship department shall be resolved through join while projects through sub-select query.
A multi-tenancy application enable a single instance of the software runs on a server, serving multiple client organizations (tenants).[1] Athena allows you to easily develop shared schema multi-tenancy applications like salesforce.com. To turn an application to multi-tenancy, you simply set the multitenancy flag in the configuration file. For example, EJBQL SELECT e FROM Employee e LEFT JOIN FETCH e.dept results the following native SQLs when multitenancy is true and false respectively:
SELECT e.employee_ID, e.fullName, e.department_ID, d.department_ID, d.nameFull FROM Employee e LEFT OUTER JOIN Department d ON e.department_ID = d.department_ID SELECT e.employee_ID, SELECT e.employee_ID, e.ORG_ID, e.fullName, e.department_ID, d.department_ID, d.ORG_ID, d.nameFull FROM Employee e LEFT OUTER JOIN Department d ON e.department_ID = d.department_ID AND d.ORG_ID = 1 WHERE e.ORG_ID = 1
As Athena handles multi-tenancy automatically, you can focus on implementing business logic.
Athena Framework is a full fledged enterprise object-relational mapping (ORM) framework that employs metadata as mapping configuration. It simplifies Flex/Flash RIA application development by providing transparent object remoting - i.e., you can manipulate objects on the client side using Flex just like on the server side using ActionScript thanks to the unified object model provided by Athena.
For many rich Internet applications, objects needs to be loaded and manipulated on the client side. Consider a very common CRUD scenario: the UI loads and displays a list of Departments objects and let the user view employees under a selected department, create and edit Department/Employees; once the user finishes the editing, he or she clicks a button to save the changes. Without a decent object manager on the client side, such kind of operation is hard to implement.
Athena offers a UnitOfWork on the client side for Flex which implements the Unit of Work pattern (plays the same role as an EntityManager in JPA context).[2] With Athena, you can implement the CRUD scenario with code shown below:
// Client side Flex code var uow:UnitOfWork = ...; var depts:ArrayCollection = ...; // Edit an dept Department(depts.getItemAt(0)).nameFull = "New Dept Name"; // Create a new dept with a new employee var dept:Department = Department.createNewInstance(); dept.nameFull = "R & D"; var emp:Employee = Employee.createNewInstance(); emp.firstName = "Alan"; emp.lastName = "Turing"; emp.department = dept; depts.addItem(dept); // Persists all changes in one shot eoService.invokeService("persistenceService", "save", [depts], onSaveSuccess, onSaveError, null);
Partial objects are objects with only some of their properties loaded. For example, we only need to load the name and other essential properties of the Employee class if we want to display a list of employees on the UI. Only the when user clicks on a certain Employee object, we then fully load the selected object. Partial object loading significantly reduces CPU, memory and network usage. Before diving into the details, you need to understand how unit of work works.
A Unit of Work keeps track of everything you do during a business transaction that can affect the database. org.athenasource.framework.eo.core.UnitOfWork is Athena's implementation of the Unit of Work pattern. UnitOfWork ensures uniqueness of EOObject. Each database record results maximum one enterprise object in a UnitOfWork.
By default, enterprise objects (instances of entity classes) returned from the server are being put into a UnitOfWork. If no UnitOfWork is specified when you make the remote call, a new instance of UnitOfWork is created for the enterprise objects returned. If the same database record is loaded again to a UnitOfWork, the existing corresponding enterprise object will be returned instead of creating a new object. Existing enterprise objects will updated if they are outdated (version lower than db). A partial enterprise object will be updated with full properties when a complete loading is performed.
To load partial objects, you simple execute EJBQLs with the special po_ attribute loading properties. For example,
var uow:UnitOfWork = new UnitOfWork("myuow"); var ejbql:String = SELECT e FROM Employee e [e.department:S]{po_e='employee_ID, firstName, lastName, department_ID'}"; eoService.invokeService("empService", "executeQuery", [ejbql], onQuerySuccess, onQueryError, uow); // returned objects will be merged into the specified unit of work.
If the user selects an employee to view the details, we need to load the full properties of the object:
eoService.invokeService("empService", "executeQuery", ["SELECT e FROM Employee e WHERE e.employee_ID = " + selectedEmp.employee_ID], onLoadFullEmpSuccess, null, uow); // specifies the same unit of work.
Once the remote call returns, a full Employee object is returned and merged into the existing UnitOfWork. Once all the properties are available, the user can see the full details of the employee.
Relationship target objects can be loaded together with the source objects in EJBQL. For example, "SELECT d FROM Department d [d.employees:S]" loads all departments with Department.employees relationship target objects (Employees). Suppose an object department with its employees relationships unresolved, any access to department.employees will trigger automatic resolution of the relationship target objects. On the server side, the resolution is performed synchronously. Due to the nature of the Flex application, the resolution is performed asynchronously.